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Executive  Summary 


The  Panel  concluded  the  concept  of  modularity  is  intuitively  simple  -  complex 
systems  are  broken  into  smaller  modules  for  better  understanding  and  manageability. 
However,  deciding  on  the  exact  and  most  beneficial  system  partitioning  can  be  a  multi¬ 
faceted  and  difficult  problem.  For  complex  Navy  systems,  the  decomposition  into  and 
selection  of  modules  will  depend  on  understanding  the  business  and  operational  drivers  for 
having  a  modular  system.  Defining  drivers  such  as  mission  reconfiguration,  technology 
refresh,  or  cost  reduction  helps  set  the  parameters  for  the  system  partitioning  and  module 
configuration. 

Second,  many  of  the  programs  examined  by  the  Panel  have  implemented  some  level 
of  modularity.  The  Panel  found  that  most  program  offices  require  modularity  in  their 
programs;  however,  implementation  details  are  left  to  the  prime  contractors  and  lead-system 
integrators.  Program  managers  provide  little  guidance  in  terms  of  configuration  for 
modularity  implementation.  While  systems  achieve  some  degree  of  modularity,  the  results 
usually  do  not  achieve  specific  business  and  operation  benefits  for  the  overall  Navy. 

Third,  the  Panel  concluded  that  as  a  starting  point  for  developing  a  process  for 
implementing  modular  systems,  the  Navy  must  define  a  taxonomy  for  modularity  that 
characterizes  the  choices  and  sets  guidance/parameters  for  implementing  modularity.  In 
particular,  the  Navy  needs  to  develop  a  systems-analysis  capability  that  looks  both  vertically 
and  horizontally  across  Navy  systems.  This  capability  will  permit  the  Navy  to  carry  out 
comprehensive  studies  of  the  cross-cutting  effects  of  modularity,  which  in  turn  will  drive 
choices  for  decomposition  across  systems  and  establish  common  drivers.  The  study  also 
concluded  that  the  Navy  must  assume  ownership  of  this  systems  engineering  process  and  can 
not  abdicate  responsibility  for  it  to  contractors. 

Finally,  the  Navy  S&T  Community  should  assist  in  developing  methodology  and 
tools  for  decomposing  systems  into  modules.  This  capability  will  help  the  Navy  define 
modularity  across  systems,  based  on  understood  drivers  and  tradeoffs.  Navy  acquisition 
managers  should  understand  the  limitations  of  the  current  methodologies,  fund  future  work  to 
develop  new  evaluation  tools,  use  innovative  platforms  to  help  verify  and  validate  module 
selection,  and  use  analytical  tools  and  test  beds  to  drive  the  decomposition  decisions. 
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REPORT  OF  THE  NAVAL  RESEARCH  ADVISORY  COMMITTEE 

Science  and  Technology  for  Modular  Systems 

Introduction 

Transformation  initiatives  introduced  to  support  the  Chief  of  Naval  Operations 
(CNO’s)  Science  and  Technology  (S&T)  Naval  Power  21  strategic  vision,  challenge  the 
Navy’s  acquisition,  requirements,  S&T  organizations;  and  Navy  industry  community  to 
provide  fleet  operators  with  new  high-perfonnance  tactical  systems  for  operations  in  an 
information-intensive,  network-centric  environment.  Constrained  budgets  for  systems 
development  and  procurement  place  a  premium  on  prudent  systems  engineering  and  modular 
design  and  construction  to  achieve  dramatic  enhancements  in  reliability,  maintainability,  and 
ease  of  technology  refresh  for  Navy  systems  while  reducing  costs.  In  recognition  of  the  new 
focus  and  importance  of  modular  designs  for  Navy  systems,  the  Assistant  Secretary  of  the 
Navy  for  Research,  Development,  and  Acquisition  (ASN(RD&A))  chartered  the  Naval 
Research  Advisory  Committee  (NRAC)  to  evaluate  the  role  of  S&T  in  Navy  systems 
engineering  for  modularity. 

The  NRAC  Panel  was  composed  of  senior  scientists  and  engineers  from  industry  and 
academia,  former  senior  government  officials,  and  retired  flag  and  general  officers  of  vast 
operational  experience.  The  Panel  studied  a  wide  range  of  current  Navy  acquisition 
programs,  system  initiatives  atU.S.  and  international  defense  companies,  and  research  efforts 
at  selected  academic  institutions.  The  resulting  recommendations  propose  a  number  of 
decisive  steps  that  exploit  the  considerable  talent  of  the  Navy’s  science  and  technology 
community  and  advocate  the  use  of  horizontal  systems  engineering  practices  for  modular 
Navy  system  designs. 
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Outline 

The  NRAC  report  on  S&T  for  Modular  Systems  is  organized  into  multiple  sections. 
The  first  section  provides  the  Panel  membership;  the  second  contains  the  specific  taskings 
from  Terms  of  Reference  (TOR)  that  guided  the  Panel;  the  third  outlines  the  approach  taken 
by  the  Panel  to  address  the  taskings  in  the  TOR;  and  the  fourth  lists  the  briefings  received  by 
the  Panel.  The  report  also  includes  an  Executive  Summary,  which  is  followed  by  several 
background  sections  covering  key  definitions,  types  of  modularity,  and  an  analysis  of  how 
modularity  can  be  beneficial  to  Navy  systems.  The  report  then  looks  at  essential  elements  of 
modular  systems  and  focuses  on  the  need  for  a  robust  Navy  process  of  systems  engineering 
and  analysis.  Subsequent  sections  summarize  the  study  findings  for  Navy  programs, 
commercial  and  defense  industries,  international  programs,  systems  engineering,  and  current 
literature.  The  final  two  sections  provide  detailed  recommendations  and  conclusions. 
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Panel  Membership 


Ms.  Teresa  B.  Smith  -  Chair 

Mr.  Noel  Longuemare 

(Northrop  Grumman) 

(Consultant,  former  PD  USD  A&T) 

Dr.  Walt  Williamson  -  Vice-Chair 

Mr.  Joseph  Y.  Rodriguez 

(Texas  Christian  University) 

(Raytheon) 

Dr.  A.  Michael  Andrews,  II 

Mr.  Richard  L.  Rumpf 

(L-3  Communications,  former  DASA  R&T) 

(Rumpf  Associates,  former  PDASN) 

Dr.  Gary  W.  Caille 

Dr.  John  C.  Sommerer 

(Georgia  Institute  of  Technology) 

(Johns  Hopkins  University-APL) 

Dr.  James  Engelland 

Mr.  William  D.  Whiddon 

(Lockheed  Martin) 

(Northrop  Grumman) 

BGen  James  M.  Feigley  USMC  (Ret.) 

Mr.  Jim  Wolbarsht 

(Consultant) 

(BearingPoint) 

RDML  Lewis  A.  Felton,  USN  (Ret.) 

RDML  Charles  S.  Hamilton,  USN 

(Perot  Systems  Government  Services) 

Executive  Sponsor 
(PEO  Ships) 

Dr.  Eric  Horvitz 

(Microsoft) 

Dr.  Richard  Vogelsong  -  Executive  Secretary 
(Office  of  Naval  Research) 

Mr.  Mark  J.  Lister 

(Sarnoff) 

Panel  Membership 

A  broad,  accomplished  panel  of  experts  contributed  to  the  NRAC  study  on  S&T  for 
Modular  Systems.  The  membership,  which  devoted  more  than  3,000  hours  to  the  effort, 
included  former  Navy  flag  and  Marine  Corps  general  officers  with  several  years  of 
experience  in  both  operations  and  acquisition;  and,  former  Senior  Executive  Service  (SES) 
members  involved  in  the  management  of  both  technology  development  and  acquisition 
programs  for  the  Office  of  the  Secretary  of  Defense  (OSD),  the  Navy,  and  the  Anny.  Other 
Panel  members  were  experts  from  defense  and  commercial  companies,  Department  of 
Defense  (DoD)  consultants,  and  senior  leaders  from  university-affiliated  research  centers  and 
academia.  The  Panel  Executive  Sponsor  was  RDML  Charles  Hamilton,  Program  Executive 
Officer  (PEO)  Ships. 
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Terms  of  Reference 


•  Review  and  assess  Navy  systems  engineering  efforts  on  programs  of 
record  and  the  extent  to  which  modular  open  systems,  provisions  for 
spiral  upgrades,  and  S&T  are  factors  in  the  requirements  definition 
and  acquisition  processes. 

•  Identify  candidate  high-payoff  S&T  areas  for  modular  development 
and  horizontal  integration,  and  assess  the  opportunities  for  S&T 
engagement  with  systems  engineering  efforts. 

•  Where  appropriate,  recommend  guidelines  for  structuring  modular 
S&  T  initiatives  that  would  enable  utilization  of  results  in  multiple 
platforms/missions  packages. 

•  Recommend  changes  required  to  improve  the  interface  between  Navy ’s 
S&T  planning  and  acquisition  processes. 


Terms  of  Reference 

The  TOR  reflected  perspectives  from  the  Office  of  the  ASN(RD&A)  and  the  Office 
of  Naval  Research  (ONR).  Initially,  the  TOR  focused  specifically  on  an  investigation  of  how 
S&T  could  support  the  development  of  modularity  in  Navy  programs.  However,  after  some 
early  discussions,  it  became  apparent  that  several  factors  are  enablers  for  modular  systems 
and  these  needed  to  be  addressed  in  the  study  discussions  as  well  as  the  S&T  elements. 
These  factors  include  items  such  as  the  acquisition  process,  spiral  development  and  systems 
engineering  processes.  In  fact,  the  Panel  determined  that  a  system-of-systems  engineering 
process  is  one  of  the  over-arching  elements  necessary  to  define  modularity  across  programs 
of  record. 

The  TOR  chartered  the  Panel  to  (1)  review  systems  engineering  and  analysis  practices 
and  processes  within  the  Navy  and  industry  and  (2)  determine  the  extent  to  which  modular 
open  systems,  spiral  upgrades,  and  S&T  are  factored  into  requirements  definitions  and  the 
acquisition  process.  The  Panel  was  directed  to  identify  S&T  areas  and  guidelines  that  could 
enhance  development  of  modular  systems  and  enable  horizontal  implementation  of  results 
across  platforms  and/or  mission  packages.  The  Panel  was  also  asked  to  recommend 
improvements  to  the  interface  between  the  Navy’s  S&T  planning  and  the  acquisition  process. 

The  complete  TOR  is  included  in  Appendix  A. 


11 


This  page  intentionally  left  blank 


12 


Approach 


Reviewed  selected  programs  of  record  for  modularity  implementation 

-  Types  of  modularity  and  drivers 

-  Degree  of  modularity  versus  integration 

-  Methodology  (systems  engineering  and  procurement  requirements) 
used  to  define  modularity 

-  Spirals  -  provisions  to  incorporate  future  capabilities  (S&T) 

-  Benefits  -  business  and  operational  cases 

Baselined  commercial  and  defense  industry  (U.S.  and  International)  for 
modularity  drivers,  business  models,  implementation  methodologies 
and  benefits 

Reviewed  systems  engineering  practices ,  especially  regarding 
modularity 

Surveyed  literature  for  implementation  methodologies,  business 
drivers,  metrics  for  measuring  success  and  prior  Government/Industry 
studies 


Approach 

The  Panel’s  approach  to  gathering  infonnation  and  data  covered  four  areas.  The 
Panel  reviewed  information  on:  selected  Navy  programs  of  record;  defense-industry 
programs,  which  included  international  projects;  and  commercial  and  academic  activities  that 
had  applicability  to  the  subject  areas.  When  reviewing  a  program,  the  Panel  looked 
specifically  for:  the  type  and  degree  of  modularity  used  in  the  system;  the  methodology  used 
to  implement  a  modular  design;  planned  spirals  and  their  relation  to  a  modular  system 
design;  and,  finally,  the  business  and  operational  benefits,  planned  or  achieved,  through 
modularity.  In  addition  to  briefings,  presentations,  and  site  visits  to  gather  basic  infonnation, 
the  Panel  conducted  a  survey  of  the  literature.  Finally,  the  Panel  examined  current  spiral 
implementation  methodologies  in  the  Department  of  the  Navy  (DoN)  and  ways  in  which  the 
S&T  community  within  the  DoN  could  contribute  to  the  long-term  development  of  a 
“modular  Navy.” 

The  resulting  information  was  grouped  into  two  basic  categories.  The  first  consisted 
of  systems  engineering  processes,  practices,  methodologies,  and  business  models.  The 
second  category  encompassed  modularity  issues  in  tenns  of  types,  implementation 
methodologies,  critical  drivers,  and  the  benefits,  liabilities,  and  metrics  associated  with 
modules  and  modular  systems. 
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Briefings  Received 

Programs 

Systems  Engineering/Other 

Industry 

•  Virginia  Class  Subs 

•  NAVSEA  05 

•  Boeing 

•  SSGN  Conversion 

•  ASN  RDA  Deputy  CHENG 

•  IBM 

•  ARCI 

•  Total  Open  System  Architecture 

•  L3  Communications 

•  CVN-21 

•  PEO  IWS  Open  System  Architecture 

•  Lockheed  Martin 

•  DD(X) 

•  Navy  Acquisition  Management 

•  Microsoft 

•  MMA 

•  NPS/Meyer  Institute  of  Systems  Eng. 

•  Northrop  Grumman 

•  J-UCAS 

•  MIT  Lean  Initiative 

•  Rockwell  Collins 

•  JTRS 

•  AF  Systems  Engineering  Forum 

International 

•  ONRFNC 

•  OSD  Open  Systems  Joint  Task  Force 

•  LCS  Seaframe 

•  OUSD  (AT&L)  -  Defense  Systems 

•  Ericsson 

•  LCS  Mission  Modules 

•  HDW 

•  Integrated  Deepwater  System 

•  Naval  Team  Denmark 

•  FCS  System  Analysis  (Sandia) 

•  Thales 

•  HSV-2 

•  X-Craft 

V 

Guidance 

•  CNR 

•  DASN  (RDT&E) 

•  PEO  Ships 

Briefings  Received 

The  study  examined  the  state  of  systems  engineering  and  modularity  for  a  total  of  14 
programs.  These  included  acquisition  category  (ACAT)  I  and  II  programs  covering  air,  sea, 
land  and  sub-surface,  as  well  as  programs  that  exhibited  a  high-degree  of  modularity.  The 
Panel  also  received  briefings  that  addressed  systems  engineering  and  modularity  from  Navy 
leaders,  including  senior  managers  from  the  Naval  Sea  Systems  Command  (NAVSEA),  the 
PEO  for  Integrated  Warfare  Systems,  Air  Force  and  DoD  officials,  and  academic  experts 
such  as  those  from  the  Massachusetts  Institute  of  Technology  (MIT)  Lean  Initiative. 

The  Panel  received  briefings  from  seven  companies  on  systems  engineering  and 
modularity  as  applicable  to  commercial  systems.  For  comparison  with  U.S.  defense 
programs,  the  Panel  visited  or  received  presentations  on  systems  engineering  approaches  and 
modular  design  by  four  European  defense  firms  as  shown  above.  The  motivation  for  and  the 
advantages/disadvantages  of  incorporating  modularity  were  an  important  element  in  both  the 
international  and  commercial  industry  discussions. 

The  Panel  received  guidance  on  structuring  its  approach  to  the  specific  taskings,  as 
well  as  structuring  fact-finding  sessions,  from  the  CNR,  Deputy  Assistant  Secretary  of  the 
Navy  (DASN)  (RDT&E)  and  the  Study  Sponsor,  PEO  Ships. 
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Bottom  Line,  Up  Front 


The  real  issue  is  a  lack  of  a  Navy-wide  Systems 
Engineering  &  Analysis  Process 

Systems  Engineering  &  Analysis  applied  horizontally  across 
programs  enables  determination  of  appropriate  modularity 


Bottom  Line,  Up  Front 

The  slide  above  provides  a  key  message  of  the  Panel’s  findings  and 
recommendations.  During  the  discovery  process,  the  Panel  determined  that  the  real  issue  is 
not  the  degree  of  modularity  or  why  or  when  it  is  implemented,  but  the  lack  of  a  Navy-wide 
systems  engineering  and  analysis  process  that  could  establish  the  rationale  for  implementing 
modularity. 

A  Navy-wide  systems  engineering  process  would  allow  the  development  of 
architectures  across  the  Navy  that  would  help  define  decisions  on  technology-development 
and  acquisition  strategies.  With  ever-increasing  system  complexity,  a  system-of-systems, 
top-down,  interactive,  recursive,  systems  analysis  process  that  defines  broad  naval 
requirements  must  be  established.  The  Panel  recommended  that  a  systems  engineering  and 
analysis  function  be  established  and  the  process  applied  horizontally  across  naval  programs 
to  enable  determination  of  appropriate  levels  of  modularity. 
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Background 


Definitions 


Systems  Engineering 

Is  a  top-down,  comprehensive,  interactive  and  recursive  system  synthesis  &  analysis 
process;  applied  through  all  stages  of  development  and  sustainment 


Integrated 

An  architectural  framework  where  most  system 
functions  are  mapped  to  single  components. 
Components  have  high  degrees  of  interdependency  and 
non-standard  interfaces. 


Modular 

An  architecture  where  system  functions  are  partitioned 
into  elements  consisting  of  various  components.  These 
elements  have  standard/defmed  interfaces  and  minimal 
interdependencies  in  the  overall  system. 
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Definitions 

One  of  the  Panel’s  observations  is  that  the  term  “modularity”  is  used  in  different 
ways;  reflecting  context,  motivations,  and  approaches.  Because  a  principle  study  finding  is 
that  systems  engineering  is  critical  to  judicious  use  of  modularity  for  Navy  systems,  the 
Panel  defines  modularity  as  one  end  of  an  engineering  spectrum,  with  highly-integrated,  or 
monolithically-engineered  systems  at  the  other  end  of  the  spectrum. 

Systems  engineering  is  the  critical  process  that  allows  an  acquisition  program  or  set 
of  programs  to  determine  the  appropriate  place  in  that  spectrum  to  optimize  the  system  being 
developed.  The  systems  engineering  analysis  must  account  for  (1)  operational  and  business 
drivers;  (2)  the  state-of-art  of  relevant  technology  and  future  development  of  that  technology; 
and  (3)  the  existence  of  or  plans  for  related  systems,  performance  requirements,  acquisition, 
logistics,  and  life-cycle  tradeoffs.  This  process  must  be  interactive  and  recursive  as  the 
system  evolves  from  conceptualization  through  acquisition  and  production,  to  test  and 
evaluation,  and  ultimately  to  operational  deployment. 

The  design  of  integrated  monolithic  systems,  at  one  extreme  of  the  engineering 
spectrum,  may  be  motivated  by  extremely  high  performance  requirements,  or  a  perception 
that  subsystem  reuse  may  be  unlikely  (e.g.,  a  highly  specialized  radio  frequency  (RF)  system) 
or  undesirable  (e.g.  anti-tamper  electronics).  In  the  context  of  software,  an  integrated 
product  may  be  characterized  as  “spaghetti  code”  because  of  the  complexity  of  data  flow,  or 
may  involve  very  powerful,  but  potentially  difficult  to  document  techniques  like  self¬ 
modifying  code.  Such  systems  are  commonly  the  products  of  small,  possibly  isolated 
engineering  teams  with  specialized  expertise.  In  general,  the  components  of  an  integrated 
system  have  a  very  high  degree  of  interdependence,  and  alteration  of  individual  components 
is  likely  to  have  a  large  number  of  collateral  effects  (in  practice,  frequently  unintended  side 
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effects).  It  is  rare  for  interfaces  between  different  components  of  the  system  to  be 
standardized.  Such  systems  present  special  challenges  for  knowledge  management  and 
technology  refresh.  It  is  even  possible  that  a  high  degree  of  systems  integration  can  impede 
competitive  procurement. 

At  the  other  end  of  the  spectrum  are  modular  systems.  Through  a  systems 
engineering  process,  such  systems  are  decomposed  into  self-contained  subsystems  that 
interact  via  well-defined  and  well-documented  interfaces.  Such  interfaces  may  even  be 
openly  documented,  by  agreement  within  consortia,  or  through  the  influence  of  the  procuring 
authority,  such  that  different  modules  may  even  be  developed  by  different  engineering  teams 
at  different  companies.  The  emphasis  on  well-documented  interfaces  between  subsystems 
represents  an  investment  or  cost  that  should  be  justified  by  the  drivers  for  the  system. 
Carefully  defining  interfaces  between  components  that  always  will  be  present  throughout  the 
system  lifecycle  represents  wasted  effort.  Technology  refresh,  maintenance,  and  multi¬ 
functionality  may  all  be  achieved  at  the  level  of  individual  modules. 

It  is  important  to  note  that  all  systems  that  incorporate  modern  technology,  even 
integrated  ones,  represent  some  degree  of  modularity.  The  key  question  for  acquisition 
programs  is  whether  the  systems  being  procured  have  the  right  degree  and  type  of 
modularity,  given  existing  operational,  business,  and  technology  drivers. 
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Background 

Types  of  Modularity 


> 

1 

Capability  Swapping 
Modularity  - 
Mission  Packages 


Component 

Sharing 

Modularity 


Bus  Modularity 


Construction/Design 
/\  Modularity 


Types  of  Modularity 

The  Panel  identified  four  types  of  modularity:  (1)  capability-swapping  modularity;  (2) 
component-sharing  modularity;  (3)  bus  modularity;  and  (4)  construction/design  modularity. 

In  capability-swapping  or  mission-package  modularity,  a  specific  package  can  be 
replaced  in  form-fit  with  another  type  of  mission  package.  The  Navy’s  Littoral  Combat  Ship 
(LCS),  which  will  accommodate  different  mission  packages  for  anti-submarine  warfare,  mine 
counter  measures,  and  anti-surface  warfare,  represents  an  example  of  this  type  of  modularity. 

Component-sharing  modularity  refers  to  the  use  of  a  specific  component  for  different 
systems  or  on  different  platforms.  For  example,  a  central  processing  unit  (CPU)  that  could 
be  used  to  perform  different  functions  on  a  platform,  or  the  same  CPU  employed  on  a  variety 
of  platform  types. 

Bus  modularity  defines  the  interactions  of  different  hardware  and  software 
components  through  a  common  backbone.  Bus  modularity  is  represented  by  system 
architectures  that  have  been  decomposed  into  modular  hardware  and  software  designs 
separated  by  a  middleware  layer.  The  middleware  layer  provides  separation  of  hardware  and 
software  as  an  alternative  to  the  tight  integration  of  the  hardware  and  software.  This 
approach  enables  independent  technology  refresh  of  both  hardware  and  software 
applications.  The  Acoustic  Rapid  Commercial-off-the-shelf  (COTS)  Insertion  (ARCI) 
program  represents  an  example  of  this  type  of  modularity. 

In  construction  or  design  modularity,  a  complex  system  is  partitioned  into 
components,  to  facilitate  design  or  manufacturing.  This  approach  can  enable  the  designers 
and  developers  to  address  each  component  separately  for  problem-solving,  manufacturing, 
testing,  and  other  program  activities,  such  that  when  all  those  components  are  brought 
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together  there  is  a  higher  likelihood  of  the  entire  system  working.  An  example  of  this 
modularity  is  the  Virginia-class  submarine  program. 
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Background 

Modularity:  Why  or  Why  Not? 


Tradeoffs 


Drivers 

•  Technology  Refresh 

•  Interoperability 

•  Increased  Readiness 

•  Mission  Reconfiguration 

•  Capability  Upgrades 

•  Construction/Manufacturing 

•  Design  Re-use  &  Qualification 

•  Logistics  &  Maintainability 

•  Training 

•  Navy  Total  Ownership  Cost 


Performance 

Development  Risk 

Flexible  &  Enhanced  Operational 

Capabilities 

Manpower  &  Skills 

Schedule/Time 

Economies  of  Scale 

Best  of  Breed  T echnology 

Acquisition  Cost 

Physical  (size,  weight,  power) 


Decisions  for  modularity  require  understanding 
operational/business  drivers  and  tradeoffs 


Modularity:  Why  or  Why  Not? 

As  a  first  step  toward  making  the  decision  about  whether  or  not  to  decompose  a 
system  into  modules,  it  is  essential  to  identify  the  drivers  for  having  a  modularity  system. 
Once  the  drivers  are  selected,  it  is  possible  to  choose  an  approach  to  modular  decomposition 
to  produce  the  effect  desired;  or,  alternatively,  determine  that  modularity  is  not  the 
appropriate  design  option.  The  Panel  identified  some  likely  drivers  as  shown  above; 
technology  refresh,  increased  readiness,  capability  upgrades,  and  reduced  total  ownership 
costs. 

Once  the  business  and  operational  drivers  are  understood,  the  implication  of  a 
modular  design  needs  to  be  recognized.  The  trade  space  may  include  positive  and  negative 
effects.  For  example,  trying  to  achieve  rapid  technology  refresh  capability  may  require  the 
system  to  be  larger,  weigh  more,  need  more  power  and  initially  cost  more.  However,  the  end 
result  will  be  a  system  that  can  easily  be  upgraded  to  better  technology,  cost  less  over  the 
total  life  span  of  the  system,  require  less  manpower  training,  and  have  reduced  development 
risk. 


Modularity  and  decomposition  choices  affect  many  parameters  including 
performance,  acquisition  costs,  and  schedule.  Thus,  the  decision  on  whether  or  not  to 
implement  modularity  should  be  based  on  an  understanding  of  both  the  near-term  and  far- 
term  operational/business  drivers  and  tradeoffs. 
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Background 

Evaluating  Modularity  Tradeoffs 


What  are  good  decompositions? 

-  Introduction  of  multiple  considerations 

—  Understanding  tradeoffs  “Minimize  interface  complexity  for 

ease  of  mission  reconfiguration” 


Evaluating  Modularity  Tradeoffs  (1) 

Technically,  all  systems  can  be  described  in  terms  of  components  and  dependencies 
among  components.  In  relatively  non-modular  or  integrated  systems,  components  are  woven 
together  tightly  and  are  not  easily  addressed  as  individual  components  for  the  purposes  of 
upgrading  (for  technical  refresh,  obsolescence,  etc.),  diagnosing,  repair,  or  reuse. 

Modular  designs  are  characterized  by  an  intelligent  partitioning  of  systems  into  sets 
of  well-defined  modules  with  clear  and  standard  interfaces.  The  modules  mask  the 
complexity  of  their  internal  designs  from  one  another  and  transmit  and  receive  only 
necessary  information  or  resources  from  other  modules  or  the  external  environment  via  the 
interfaces. 

Typically,  there  are  multiple  ways  to  partition  systems  into  modules.  Decisions  about 
the  decomposition  or  partitioning  of  a  system  into  well-defined  modules  have  been  part  of 
the  heuristic  art  of  systems  engineering.  In  the  past,  such  partitioning  has  relied  on  the 
intuitions  of  engineers  or  been  split  along  lines  of  demarcation  from  roles  that  different  sets 
of  components  might  play  in  a  system.  Other  times,  the  partition  is  based  upon  the  provision 
of  different  types  of  components  by  specific  groups  or  organizations  recognized  as  expert 
sources  for  those  particular  components  or  modules. 

There  is  opportunity  for  developing  methods  and  tools  for  reasoning  about  the  costs, 
benefits,  and  tradeoffs  associated  with  different  decompositions.  The  relative  value  of 
different  system  decompositions  and  the  associated  modules  generated  by  the  partitions, 
depend  on  key  desired  attributes. 

The  tightly  integrated  system  (diagram  on  Slide-left)  can  be  decomposed  in  different 
ways  depending  on  objectives.  For  example,  if  the  goal  is  to  minimize  the  complexity  of 
interfaces  among  modules,  the  system  could  be  decomposed  in  two  modules  with  three 
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simple  interfaces,  as  shown  on  the  right  side.  In  developing  such  a  decomposition,  a  utility 
or  objective  function  might  capture  a  measure  of  the  cost  associated  with  maintaining  and 
writing  modules  that  are  consistent  with  and  abide  by  the  defined  interfaces.  Such  an 
objective  function  might  evaluate  the  cost  of  an  overall  system  as  being  some  monotonically 
increasing  function  of  the  number  of  interfaces. 
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Background 

Evaluating  Modularity  Tradeoffs 


What  are  good  decompositions? 

-  Introduction  of  multiple  considerations 

-  Understanding  tradeoffs 

Prepare  for  technical  refresh  of  A 


Integrated  system 


Evaluating  Modularity  Tradeoffs  (2) 

Consider  now  decompositions  aimed  at  another  objective — that  of  preparing  for  new 
technology  insertion,  based  on  expectations  about  a  fast-paced  competitive  area  of 
technology.  If  the  goal  of  decomposition  is  to  prepare  for  a  technical  refresh  of  a  set  of 
components  that  comprise  the  module  (subsystem  A),  a  different  partition  of  components  of 
modules  may  be  more  valuable.  In  this  case,  preparing  for  the  technical  refresh  of 
technologies  embodied  by  components  in  subsystem  A  requires  a  greater  number  of 
interfaces  than  the  system  partition  shown  on  the  previous  page.  However,  in  the  future, 
subsystem  A  can  be  easily  decoupled  and  replaced  with  updated  technology. 
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Background 

Evaluating  Modularity  Tradeoffs 


What  are  good  decompositions? 

-  Introduction  of  multiple  considerations 

-  Understanding  tradeoffs  “Prepare  for  technical  refresh  of  A, 

and  ready  for  failure  of  B” 


Integrated  system 


Evaluating  Modularity  Tradeoffs  (3) 

For  system  design,  assuming  a  single  objective  often  is  unrealistic;  co-existence  of 
multiple  objectives  is  more  common.  The  illustration  above  is  an  example  of  two  objectives. 
A  designer  may  seek  both  technical  refresh  of  A,  and  also  the  cost-effectiveness  of  replacing 
a  subset  of  components,  contained  in  Module  B,  that  are  known  to  have  a  short  mean  time  to 
failure  relative  to  other  components  in  Module  B.  Now,  another  decomposition,  that  of 
partitioning  out  Module  C  from  other  components  in  Module  B,  may  lead  to  cost  savings  and 
higher  operational  availabilities.  The  new  decomposition,  while  it  may  promise  to  yield  a 
system  that  is  less  expensive  to  maintain,  contains  a  new  module,  as  well  as  additional 
associated  interfaces  between  the  new  module  and  other  modules  in  the  system. 

Multiple  objectives  should  be  identified  and  reviewed;  attributes  of  some  or  all  of 
these  objectives  may  be  in  conflict;  leading  to  consideration  of  tradeoffs  in  detennining  good 
partitions.  Decisions  on  decompositions  into  modules  must  be  sensitive  to  the  objectives.  A 
fundamental  starting  point  for  analyzing  the  value  of  alternative  partitions  is  a  clear  and 
explicit  definition  of  desired  attributes  followed  by  a  qualitative  or  quantitative  exploration  of 
the  benefits,  costs,  and  tradeoffs  associated  with  different  system  decompositions. 

Although  there  is  opportunity  for  formal  mathematical  optimization  as  part  of  a 
methodology  for  decomposition  of  a  system  into  modules,  considerations  of  multiple 
objectives  and  alternate  decompositions  can  be  used  to  build  insights  during  typical 
qualitative  design  evolutions. 

Insights  about  alternative  decompositions  and  better  choices  for  ultimate 
modularization,  can  be  achieved  by  assessing  multiple  objectives  that  capture  differing 
intentions  behind  developments  of  systems.  Such  objectives  should  be  shared  among 
involved  parties  and  refined  as  part  of  the  process  of  deliberating  about  alternative 
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decompositions.  The  availability  of  the  objectives  can  support  deliberation  about  measures 
of  goodness  of  different  system  decompositions. 
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Pillars  of  Modular  Systems 


•  Systems  Engineering 

•  Standard  Interfaces 

•  Open  System  Architecture 


Systems  Engineering  Drives  Standards 
and  Open  System  Architecture 


Pillars  of  Modular  Systems 

As  the  Navy  seeks  to  harvest  the  benefits  of  modularity  to  support  and  enhance  naval 
warfighting  capability,  three  technical  “pillars”  must  be  considered:  systems  engineering, 
standard  interfaces,  and  open  systems  architectures.  The  pillars  represent  processes  that 
allow  decisions  concerning  modularity  to  be  based  on  requirements  for  joint  interoperability, 
horizontal  utility,  and  compatibility  across  naval  programs  and  platforms. 

Systems  Engineering :  A  systems  engineering  process  is  essential  for  examining  and 
determining  the  driving  factors  for  modularity.  A  systems  engineering  process  consists  of 
two  elements:  first,  the  technical  knowledge  needed  to  engineer  specific  systems;  and  second, 
the  systems  engineering  management  that  permits  the  engineering  of  systems-of-systems,  at 
the  highest  programmatic  level,  to  ensure  that  decisions  are  based  on  organized  input  and 
analysis.  The  systems  engineering  management  process  must  be  a  top-down,  comprehensive, 
interactive,  and  recursive  problem-solving  process  that  is  applied  sequentially  through  all 
stages  of  development  and  sustainment. 

Standard  Interfaces :  Standard  interfaces  go  hand-in-hand  with  open  systems 
architectures.  Open  systems  architecture  definitions  are  intended  to  define  non-proprietary 
interfaces  that  are  available  to  all  suppliers.  Free  access  to  interface  standards  fosters  a 
competitive  environment,  which  should  encourage  expanded  product  innovation  and  result  in 
“best-of-breed”  capability  at  lowest  cost.  In  order  for  modules  to  be  used  in  multiple 
applications,  interfaces  must  not  only  be  “open,”  but  also  be  common  or  standard.  For 
example,  if  several  platforms  choose  to  use  computers  that  interface  with  open  systems, 
computer  modules  cannot  be  used  on  multiple  platforms  unless  they  incorporate  the  same 
open  system  interfaces.  Some  level  of  standardization,  even  for  so-called  “open”  systems, 
must  be  adopted  to  maximize  the  benefits  of  interchangeable  modules. 
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Open  Systems  Architectures :  Open  systems  architectures  permit  the  use  of  common 
modules  across  multiple  systems  by  enabling  the  design,  engineering,  acquisition,  testing, 
and  fielding  of  non-unique  modular  components.  As  noted  in  the  charter  for  the  Open 
Systems  Joint  Task  Force  (OSJTF),  “  an  opportunity  exists  to  make  a  significant  impact  on 
the  cost,  interoperability,  modularity,  technology  transparency,  supportability,  and  a  host  of 
other  important  aspects  of  the  electronics  in  future  weapon  systems  by  sponsoring  and 
accelerating  the  adoption  of  an  open  systems  approach  for  new  systems  and  system 
upgrades.”  Although  these  words  address  open  systems  associated  with  electronic 
components,  they  are  applicable  equally  to  all  systems  that  are  attempting  to  gain  the  benefits 
of  modularity. 
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Background 

Systems  Engineering 


Platform/Program  Model 


Systems  Engineering  (1) 

The  slide  above  shows  the  nominal  “concept  to  material”  systems  engineering 
process  currently  used  by  the  Navy.  It  is  a  vertical,  single-dimensional  methodology  that 
derives  individual  platform  requirements  from  over-arching  Navy  operational  concepts.  This 
platform/program  model  does  not  provide  a  construct  by  which  to  identify  or  evaluate  similar 
needs  across  multiple  platforms  or  to  attain  interoperability  benefits.  The  same  holds  true  for 
intra-system  modularity  requirements.  Modularity  only  occurs  by  fiat  (via  a  Concept 
Requirements  Document  (CRD)  statement). 

The  other  most  significant  limitation  to  this  model  is  that  any  system-of-systems 
integration  that  takes  place,  does  so  in  the  fleet  or  operating  forces.  This  places  a  significant 
burden  on  the  forces  because  of  the  competing  realities  of  optempo  and  the  need  for 
resources  to  conduct  unplanned  systems  integration  functions.  This  “product-line”  or 
“stovepipe”  model  has  well-recognized  and  well-understood  limitations;  not  the  least  of 
which  is  an  inadequate  process  for  systems  engineering  and  interoperability. 
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Systems  Engineering  (2) 

The  horizontal  integration  model  above  for  system-of-systems  engineering  is  an 
interactive  model  consisting  of  three  elements:  the  customer  (concepts),  the  acquisition 
process  (Requirements  and  Integration),  and  the  S&T  community  (designs). 

The  Top-Down  element  is  composed  of  the  capability-based  methodology  that  starts 
with  strategic  direction.  The  strategic  direction  flows  from  joint  operational  concepts,  joint- 
service  operating  concepts,  and  joint  capability. 

The  second  element  of  the  model  performs  a  Gap  Analysis  of  the  system-of-systems 
to  uncover  weaknesses  in  current  plans.  The  analysis  is  based  on  the  joint  capabilities 
assessment,  which  is  provided  by  the  topdown  systems  engineering  element.  A  Bottom-Up 
element  provides  current  system  capabilities  and  technologies.  Alternatives  postulated  from 
the  Bottom  Up  analysis  feed  into  the  Gap  Analysis  process  and  are  viewed  within  the  context 
of  the  Top  Down  analysis  to  determine  individual  comparative  worth.  The  resultant  analysis 
forms  the  basis  for  future  system  requirements. 

The  Bottom-Up  element  takes  the  requirements  from  the  Gap  Analysis  and  performs 
the  detailed  physics-based  design/sy stems  engineering.  It  does  tradeoffs,  CONOPS 
assessment,  evaluation  of  various  measures  of  effectiveness  (MOEs),  measures  of 
performance  (MOPs),  interdependencies,  and  total  cost  of  ownership,  among  others.  From 
this  assessment,  spiral  technology  development  programs  which  encompass  technology- 
insertion  options,  are  presented  for  the  Gap  Analysis.  Development  options,  when  refined 
further,  are  presented  as  recommendations  to  the  Top-Down  element,  which  reviews  them 
and  forwards  them  to  the  Navy’s  Program  Objective  Memorandum  (POM). 
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Findings 

The  Panel’s  findings  are  grouped  into  five  categories: 

•  Navy  Programs 

•  U.S.  Industry 

•  International  Programs  &  Industry 

•  Systems  Engineering 

•  Literature  Survey 

The  following  section  describes  the  key  findings  in  each  of  these  areas  and  sets  the 
context  for  the  final  recommendations  and  conclusions. 
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Navy  Program  Findings 


•  No  actionable  policy,  guidance,  definitions,  or  principles  for  modularity 

•  Shortage  of  systems  engineers  and  lack  of  experience  with  modularity 

Decision  Process 

•  Motivators  for  modularity  not  understood  or  articulated 

•  Inconsistent  system  analysis  (if  any),  program/platform  centric,  done  by 
primes 

Acquisition  Implementation 

•  LCS,  SSGN,  and  ARCI  reflect  transformational  use  of  modularity 

•  In  general,  programs  have  delegated  decision  responsibility  for  modularity 
to  primes  without  guidelines  or  incentives 

•  No  serious  commitment  to  spiral  development  observed;  S&T  community 
largely  decoupled 

•  Impact  of  modularity  on  T&E,  training,  and  logistics  not  well  understood 


Navy  Program  Findings  (1) 

Among  the  programs  reviewed,  including  the  ones  that  have  embraced  some  degree 
of  modularity,  none  were  structured  based  on  any  Navy  policy  or  formal  Navy  guidance  on 
modularity.  The  Panel  determined  that  no  consistent  definition  of  “modularity”  or  “standard 
interfaces”  exists.  Second,  all  PEOs  and  program  managers  (PMs)  interviewed  reported  a 
shortage  of  systems  engineers.  In  general,  the  Panel  concluded  that  very  few  engineers  were 
available  who  were  experienced  with  modular  systems. 

Decision  Process:  The  Panel  found  that  the  reasons  for  using  modularity  are  neither 
well-understood  nor  well-articulated.  The  Panel  attributed  this  shortcoming  to  the 
inconsistency  of  available  modular-systems  analyses  and  the  relative  newness  of  approaches 
for  assessing  capabilities  in  a  net-centric  warfare  environment  versus  assessing  platfonn 
requirements  to  meet  mission  objectives. 

Acquisition  Implementation:  The  following  are  some  of  the  general  findings  the 
Panel  cited  relative  to  the  acquisition  process. 


•  Three  of  the  programs  reviewed,  the  LCS,  cruise  missile  submarine  (SSGN),  and 
the  ARCI  (Acoustic  Rapid  Cots  Insertion)  program,  are  good  examples  of 
modularity  and  reflect  a  paradigm  shift  in  Navy  acquisition  programs.  These 
programs  understood  the  drivers  for  modularity  and  had  established  parameters  for 
decomposition  based  on  these  drivers. 

•  Several  of  the  new  programs  reviewed  addressed  a  spiral  development  structure 
within  their  acquisition  model.  Yet,  all  of  the  program  managers  who  briefed  the 
Panel  reported  that  there  was  no  firm  plan  or  funded  program  structure  within  the 
S&T  community  to  underpin  this  acquisition  program  and  to  ensure  success  and 
reduce  risk  through  spiral/modular  developments. 
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•  Due  to  the  lack  of  quality  and  numbers  of  systems  engineers  and  the  lack  of  firm 
guidance  or  policy  on  modularity,  most  program  managers  have  delegated  the 
decision  for  modularity  to  their  prime  contractors  or  LSIs  without  contractual 
incentives. 

•  The  Panel  felt  that  the  Navy  could  benefit  greatly  from  modularity  implementation 
in  three  areas  —  test  and  evaluation  (T&E),  training,  and  logistics.  However,  the 
Panel  did  not  find  a  Navy  program  official  who  could  quantify  the  effect  of  cost  or 
schedule  on  development  or  operational  testing  (DT/OT)  if  modularity  were 
employed  in  their  programs.  Likewise,  the  impact  of  modularity  on  training 
requirements  and  logistics  support  was  not  understood  by  program  managers. 
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Navy  Program  Findings 


Examples  of  Best  Practices 

•  LCS,  SSGN:  Navy  taking  responsibility  for  upfront  SE 

•  ARCI:  good  use  of  modularity,  spiral  development,  commercial  standards, 
&  technology  to  enhance  capability 

•  Virginia  Class:  good  example  of  benefits  of  modular  construction 

•  X-Craft  and  HSV2  potential  test  beds  for  SE  and  operational  mission 
module  evaluations 


Areas  for  Improvement 

•  UUVs  (approximately  70  types):  lack  of  modularity,  policy,  guidance,  and 
standards 

•  MMA:  program  office  and  prime  have  different  visions 

•  MMA,  ACS,  BAMS,  J-UCAS:  minimal  horizontal  systems  engineering 

•  LCS  and  Deepwater:  MOU  in  place;  questionable  commitment 

•  DD(X),  CG(X),  CVN21:  technology  sharing  opportunity 

•  FORCEnet:  System  of  Systems  Engineering  an  absolute  requirement 


Navy  Program  Findings  (2) 

Examples  of  Best  Practices ;  The  Panel  found  examples  of  best  practices  for  modularity  in 
several  individual  programs.  The  LCS  and  SSGN  programs  reflect  cases  in  which  the  Navy 
demanded  modularity  for  capability-swapping  of  mission  modules  to  provide  flexible 
operations.  The  ARCI  took  the  initiative  to  reduce  cost  and  yet  achieve  technology  refresh 
by  using  component  and  bus  modularity,  spiral  development,  and  commercial  standards  to 
enhance  capability  through  technology  insertion  and  refreshment.  The  Panel  considered  the 
Virginia-class  submarine  program  to  be  an  excellent  example  of  modular  construction  that 
has  matured  to  an  even  higher  level  than  its  predecessor,  the  Seawolf  class  —  the  first 
submarine  program  in  which  modular  construction  was  used. 

The  Panel  felt  the  joint  service  HSV-2  and  the  Office  of  Naval  Research  X-Craft 
programs  offer  promising  testbeds  for  systems  engineering  and  mission  module  evaluation. 
Their  flexible  cargo  area  designs  will  provide  the  Navy  with  very-affordable,  quick-look 
evaluations  of  new  mission  modules  while  in  an  early  prototype  phase,  offering  the  potential 
of  finding  design  flaws  that  would  cost  more  to  correct  in  a  later  stage  of  system  maturity. 

Areas  for  Improvement  The  PEO  for  Littoral  and  Mine  Warfare  (LMW),  in  briefing  the 
Panel,  reported  that  the  Navy  has  developed  70  different  types  of  unmanned  underwater 
vehicles  (UUVs) — a  clear  example  of  the  lack  of  modularity  policy,  guidance,  and  standards. 

In  a  related  example,  the  Navy  program  manager  for  the  Multi-Mission  Aircraft 
(MMA)  program  told  the  Panel  that  the  contractor  would  be  providing  an  airborne  “truck”  to 
replace  the  aged  P-3  airframe  while  retaining  the  mission  equipment.  Yet  the  MMA  prime 
contractor  openly  applauded  the  opportunity  to  insert  common  mission  modules  from  other 
programs,  taking  advantage  of  newer  technology  and  an  open  systems  architecture  to  support 
modularity  and  lower  total  cost  of  ownership  from  an  acquisition  support  and  training 
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perspective.  These  different  views  demonstrated  the  lack  of  coordination  in  the  Navy  and 
contractor  influence  in  modular  system  designs. 

The  Panel  concluded  that  other  new  programs,  including  the  Aerial  Common  Senor 
(ACS),  Broad  Area  Maritime  Surveillance  (BAMS),  and  Joint  Unmanned  Combat  Air 
System  (J-UCAS)  all  could  benefit  from  effective  horizontal  systems  engineering  and 
analysis.  The  payloads,  peripherals  and  backbone  architecture  for  these  systems  appeared  to 
be  ripe  areas  for  developing  commonality. 

The  Panel  also  initially  noted  a  questionable  commitment  on  behalf  of  the  Coast 
Guard  and  its  contractor,  Integrated  Coast  Guard  Systems  (ICGS),  to  work  together  on  a 
common  seaframe  (HM&E)  and  other  common  equipment  which  could  satisfy  both  the 
Navy’s  LCS  and  the  Coast  Guard’s  national  security  cutter  requirement,  even  though  a 
memorandum  of  understanding  (MOU)  was  in  place  between  PEO  (Ships)  and  PEO 
Integrated  Deepwater  Systems  (IDS).  However,  the  Panel  was  later  advised  that  the  Coast 
Guard  plans  to  assign  10  personnel  to  the  Navy’s  X-Craft  crew,  an  indication  of  Coast  Guard 
interest  in  a  more  cooperative  role  on  the  LCS  program. 

The  Panel  also  concluded,  that  in  addition  to  potential  radar  designs  and  antennas, 
other  areas  of  commonality  can  be  identified  among  the  Navy’s  DD(X),  CG(X),  and  CVN-21 
programs.  The  Panel  considered  FORCEnet  to  be  an  example  of  a  major  effort  that  requires 
a  system-of-systems  engineering  discipline  to  ensure  success  for  this  very  complex  net- 
centric  program. 
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tBBE - 

I  U.S.  Industry  Findings 


•  No  common  definitions  or  standards  for  modularity  ( Defense ) 

•  Company  interests  dominate  modularity  decisions  ( Defense ) 

•  Need  for  Systems  Engineering  recognized,  not  uniformly  implemented,  and  shortage 
of  expertise  ( Defense  &  Commercial) 

•  Software  an  enabler  for  open-system  architectures  and  modularity  (Defense  & 
Commercial) 

•  Low  percentage  of  software  re-use;  high  opportunity  for  cost  savings  ( Defense  & 
Commercial) 

Defense  Industry  Specifics 

•  Capability  Swapping  Modularity/Mission  Packages  -  industry  not  developing 
unless  directed  by  government 

•  Construction/Design  Modularity  -  both  government  and  industry  in  harmony 

•  Bus  Modularity  -  commercial  companies  ahead  of  defense  in  implementation 

•  Component  Sharing  Modularity  -  defined  by  company  business  models  not  by 
customer 


U.S.  Industry  Findings 

The  Panel  received  briefings  from  Boeing,  IBM,  L3  Communications,  Lockheed 
Martin,  Microsoft,  Northrop  Grumman,  and  Rockwell  Collins.  The  topics  included:  the 
application  of  modular  systems  to  multiple  platforms  or  systems;  systems  engineering 
principles  for  modular  open  system  architectures  (MOSA);  processes,  guidelines,  and  metrics 
for  modularity;  and  S&T  recommendations  to  enable  MOSA  development  and 
implementation.  The  companies  also  were  asked  to  provide  examples  of  programs 
employing  MOSA  across  multiple  platforms  and  recommendations  for  future  programs. 

In  general,  the  Panel  found  that  defense  companies  were  requested  but  not 
incentivized  by  their  DoD  customers  to  provide  modularity.  Companies  described  some 
examples  of  modularity  that  supported  multiple  programs,  but  these  modular  designs  and 
their  applications  were  based  on  internal  business  decisions.  Companies  with  both 
commercial  and  defense  business  sectors  provided  examples  of  how  modular  designs  were 
used  between  sectors.  In  conclusion,  the  use  of  modularity  seemed  to  depend  mostly  on 
internal  business  models  and  only  to  a  limited  degree  on  DoD  customer  direction. 

The  Panel  found  that  all  companies  embraced  systems  engineering  as  a  key  set  of 
processes  for  design  and  management.  Yet  the  companies  provided  many  different  views  on 
the  topic,  not  only  in  terms  of  the  scope  of  systems  engineering,  but  also  in  the  use  and 
definition  of  terms.  Many  of  the  companies  viewed  the  scope  of  systems  engineering  only  in 
tenns  of  specific  individual  products,  or  program  stovepipes.  Few  addressed  the  expanded 
scope  of  integration  across  programs  as  a  system  of  systems.  The  Panel  felt  this  lack  of 
common  understanding  of  systems  engineering  concepts  has  caused  confusion  and  restricted 
the  Navy’s  progress  in  achieving  intelligent  use  of  modularity.  For  example,  the  tenns  “open 
systems”  and  “modularity”  were  used  interchangeably,  although  they  are  not  the  same. 
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The  Panel  also  noted  differing  interpretations  of  “modularity”  both  in  terms  of  the 
levels  of  a  system  to  which  it  is  applied,  and  in  terms  of  type  of  modularity  being  used.  To 
evaluate  these  diverse  views,  the  Panel  adopted  two  frames  of  reference:  the  level  of 
application  and  the  type  of  modularity.  The  level  of  application  looked  at  (a)  weapon-system 
level  (a  Navy  warfighter  issue);  (b)  system  level  (an  acquisition  and  prime  contractor  issue); 
(c)  subsystem  level;  and  (d)  component  level.  The  type  of  modularity  looked  at  (a) 
mission/package  modularity,  (b)  bus  modularity,  (c)  component-sharing  modularity,  and  (d) 
construction/design  modularity  being  used. 

Although  industry  used  modular  approaches  during  World  War  II  to  build  vast 
numbers  of  ships,  it  wasn’t  until  the  1970s  that  the  Navy  began  to  reconsider  modular 
approaches.  Currently  there  are  few  examples,  such  as  LCS,  SSGN,  and  ARCI,  where  the 
Navy  has  asked  industry  to  use  mission  modular  approaches.  The  Panel  found  that  if  the 
Navy  does  not  request  a  modularity-based  approach,  industry  will  detennine  whether  or  not 
to  use  modular  designs  based  on  business  interests. 

The  Panel  heard  from  industry  about  a  variety  of  company  motivators.  Examples  of 
these  are:  improving  competitive  position,  reducing  production  costs,  and/or  maximizing 
reuse  of  products  across  programs.  The  Panel  asked  companies  to  address  their  systems 
engineering  principles  for  MOSA.  One  company  cited  the  new  OSD  Task  Force  report,  “A 
Modular  Open  Systems  Approach  to  Acquisition  -  Version  1.2,  February  2004,”  as  an 
excellent  description  of  MOSA  principles  and  benefits.  The  companies  described  the 
importance  of  systems  engineering  and  their  particular  implementation  approaches  for 
different  levels  of  modularity.  However,  when  reviewing  company  integrated  technical  and 
business  strategies,  the  Panel  found  that  industry  does  not  have  an  unifonn  process  for 
implementation  of  systems  engineering.  More  important,  given  such  diversity,  the  Navy  has 
no  standard  method  for  judging  the  quality  of  the  systems  engineering  approaches  of 
different  companies  either  during  proposal  evaluation  or  during  execution  phases  of 
programs. 

The  Panel  also  found  a  shortage  of  systems  engineers  in  both  industry  and 
government.  During  the  past  decade  the  government  experienced  roughly  a  50  percent 
reduction  in  people  associated  with  systems  engineering  (Hon.  Michael  Wynne,  in  Defense 
AT&F  Magazine,  July-August  2004).  Industry  also  saw  significant  reductions  in  its  systems 
engineering  workforce. 

A  common  theme  that  emerged  during  the  industry  briefings  is  that  software  is  a  key 
enabler  for  achieving  meaningful  and  effective  modularity.  Clearly,  as  systems  have  moved 
toward  digital  implementation,  developers  have  moved  rapidly  toward  making  the  hardware 
generic  and  common,  with  functionality  resident  in  the  software.  As  a  result,  many  of  the 
commercial  pressures  that  have  driven  the  electronics  and  software  industries  toward  object- 
oriented  software  and  plug-and-play  hardware  interfaces  are  also  driving  defense  systems. 
The  Panel  felt  that  the  Navy  must  require  that  system  architectures  are  “open”  to  ensure  the 
long-  tenn  ability  to  competitively  facilitate  technology  and  functional  modular  upgrades. 

In  terms  of  weapon  system  modularity,  Navy-industry  teams  of  necessity  have 
evolved  the  construction  and  modular  design  of  weapon  system  platforms  since  early  1972. 
Completed  modules  are  assembled,  integrated,  and  tested  before  they  are  joined.  This  type  of 
modularity  was  driven  primarily  by  two  factors:  first,  considerations  of  the  viability  of  the 
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industrial  base;  and  second,  cost.  For  example,  the  Virginia  class  attack  submarine  program 
was  developed  by  two  shipyards,  General  Dynamics  Electric  Boat  and  Newport  News,  and  is 
being  built,  assembled  and  tested  in  both  locations.  This  same  philosophy  has  been  applied 
to  surface  ships  and  aircraft. 

Weapon  system  developments  have  been  driven  by  software  complexity.  Prior  to  the 
emphasis  on  open  system  architectures,  adding  or  improving  a  function  for  a  defense  weapon 
system  was  expensive  and  time  consuming.  Most  weapon  systems  are  tightly  integrated  and 
make  limited  use  of  standard  interfaces  and  have  been  developed  primarily  by  commercial 
companies.  New  systems  being  developed  for  the  Navy,  Army,  and  Air  Force  have  started  to 
introduce  open  system  architectures.  Some  examples  include  Navy  Multi-Band  Terminal 
(NMT)  and  the  Joint  Tactical  Radio  System  (JTRS).  In  theory,  open  architectures  pennit 
adding  functions  as  software  applications  without  the  need  to  change  hardware,  promoting 
competition  on  the  function  or  waveform  as  long  as  the  hardware  and  software  interfaces  are 
clearly  defined.  But,  because  standards  don’t  exist,  hardware  and  software  interfaces  and 
protocols  are  left  to  the  individual  contractors.  Thus,  the  customer  may  not  achieve 
modularity  between  platforms  and  be  saddled  with  proprietary  systems. 

When  the  Navy  asks  industry  to  respond  to  a  stated  modularity  need  without  clear 
guidance,  companies  will  look  first  to  their  internal  products.  Company  objectives  are  to 
maximize  their  particular  modular  approach  across  as  many  of  their  own  platforms  as 
possible  and  achieve  economies  of  scale  for  price  competitiveness.  Although  this  is  not 
necessarily  an  inadequate  response  to  a  modularity  need  for  a  platfonn,  it  may  come  with 
company  proprietary  limitations.  From  a  DoN  perspective  of  looking  horizontally  across 
many  different  platforms,  a  single  company’s  modularity  approach  may  not  produce  the 
desired  DoN  product  with  its  particular  performance,  size,  or  other  commonality 
characteristics. 
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International  Findings 


•  Global  Market  Drives  Business  Behavior 

•  Effective  Joint  Government-Industry  Collaborations 

-  Naval  Team  Denmark 

•  European  defense  products  reviewed  incorporate  more  modularity  than  U.S. 

-  Systems  Engineering  used  to  determine  type  and  degree  of  modularity 


International  Findings 

The  Panel’s  interactions  with  overseas  firms;  selected  because  they  achieved  some 
desirable  goals  through  modularity;  illustrated  the  potential  impact  of  a  constrained 
acquisition  environment  in  motivating  systems  engineering  and  modularity.  The  Panel 
recognized  that  operational  commitments,  capabilities  achieved,  and  government-industry 
relations  differ  considerably  in  Europe  from  the  United  States.  The  Europeans  have 
embraced  and  engineered  modularity  to  their  benefit  in  a  constrained  environment.  The 
United  States  may  face  different  constraints,  but  it  is  likely  that  a  systems  engineering 
process  similar  to  that  employed  by  the  European  companies  would  help  the  U.S.  face  those 
constraints  with  similar  or  greater  success. 

First,  the  European  governments  procure  for  their  domestic  use  smaller  numbers  of 
systems  than  U.S.  defense  contractors,  therefore,  requiring  access  to  a  global  export  market 
to  achieve  economies  of  scale  and  amortize  costs  of  non-recurrent  engineering.  Modularity 
plays  an  important  role  in  allowing  the  delivery  of  customized  products  that,  for  the 
importing  customer,  are  both  valuable  and  affordable.  Further,  the  need  to  access  non¬ 
domestic  markets  encourages  more  flexibility  in  business  behavior  (such  as  partnerships, 
joint  ventures,  consortia,  and  open  architectures)  than  has  been  common  among  United  States 
defense  contractors. 

Second,  the  Panel  observed  that  the  Europeans  have  employed  government-industry 
collaborations  successfully:  to  facilitate  the  systems  engineering  process,  to  help  define  and 
articulate  interface  standards,  and  to  socialize  procurement  approaches.  Naval  Team 
Denmark  represents  an  outstanding  example  of  government  leadership  of  a  collaborative 
systems  engineering  process  that  met  Danish  Navy  needs  within  a  constrained  environment. 
The  Danish  government-industry  collaboration,  also,  did  not  interfere  with  the  integrity  of 
the  competitive  procurement  process. 
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The  Panel  emphasizes  that  the  European  examples  show  strong  systems  engineering 
and  a  clear  understanding  of  underlying  motivations  behind  their  employment  of  modularity. 
The  Panel  did  not  see  modularity  pursued  as  a  purely  aesthetic  or  stylistic  approach. 
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International  Findings 


Specific  Examples 


Primary  Motivation 


Approach 


HDW /  small  submarines 
(i Construction  Modularity ) 


Custom  offerings  to  diverse 
market  (design  reuse) 
Construction  efficiency 


Modular  hull  sections 
Optional  capabilities 


International  Findings  (2) 

The  Panel’s  fact-finding  sessions  with  international  industry  representatives 
indicated,  in  general,  a  more  open  embrace  of  modularity  than  their  U.S.  defense  industry 
counterparts.  The  Panel  observed  examples  of  each  of  the  four  types  of  modularity  discussed 
earlier. 

Howaldtswerke-Deutsche  Werft  (HDW)  of  Germany  aggressively  employs 
construction/design  modularity  to  customize  their  submarines  in  order  to  appeal  to  a  diverse 
market.  This  customization,  enabled  by  the  use  of  modularity,  allows  customers  to  select 
from  various  options  when  specifying  systems.  As  a  result,  HDW  sells  submarines  to  a 
variety  of  nations  and  customers. 
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International  Findings 


Specific  Examples 

Primary  Motivation 

Approach 

HDW  /  small  submarines 

(Construction  Modularity ) 

■  Custom  offerings  to  diverse 
market  (design  reuse) 

•  Construction  efficiency 

•  Modular  hull  sections 
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International  Findings  (3) 

The  Stanflex  family  of  small  vessels,  developed  under  Danish  government  leadership 
by  Naval  Team  Denmark,  demonstrates  the  implementation  of  capability-swapping 
modularity.  This  approach  was  guided  by  the  Danish  Navy’s  need  to  meet  a  variety  of 
operational  commitments,  some  distinctly  non-military,  with  a  very  limited  number  of 
platforms.  Through  careful  systems  engineering,  they  met  their  planned  commitments  by 
developing  interchangeable  mission  modules  with  standardized  interfaces  for  power,  hotel 
plant,  and  data. 

A  collateral  benefit  of  the  Stanflex  system-of-systems  has  been  increased  readiness, 
since  the  combat  systems  within  the  architecture  can  be  maintained  and  tested  ashore.  The 
approach  also  simplifies  training  of  both  operators  and  maintenance  technicians.  Rapid 
reconfiguration  of  naval  vessels— within  a  few  hours— is  possible  with  minimal  shore-side 
infrastructure,  suggesting  forward  area  reconfiguration  is  eminently  practical. 

The  Stanflex  system  has  been  sufficiently  successful  that  it  has  been  extended, 
essentially  unchanged,  to  the  next  generation  of  substantially  larger  offshore  patrol  vessels 
and  frigate-class  flexible  support  ships.  Notwithstanding  different  drivers,  the  Panel  feels 
that  the  Stanflex  effort  is  a  best-of-class  example  that  is  significantly  relevant  to  the  U.S. 
LCS  program. 
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International  Findings  (4) 

The  Panel  observed  several  examples  of  bus  modularity  in  European  programs. 
Those  examples  reflected  several  diverse  driving  factors  or  motivations.  One  motivation  was 
to  enable  straightforward  capability  upgrading  by  allowing  software  modules  to  be  changed 
as  required.  Another  driving  factor  was  the  ability  to  reuse  either  internal  or  third  party 
applications.  This  approach  enabled  customers  or  other  developers  to  add  sensitive  or 
proprietary  modules,  even  while  interacting  with  the  rest  of  the  systems  through  standard 
interfaces. 

Additionally,  several  of  these  architectures  were  scalable,  thus  able  to  support 
requirements  from  a  variety  of  potential  customers.  This  scalability  was  facilitated  by  the 
implementation  of  an  open  architecture.  Taken  together,  these  factors  permitted  additional 
global  market  penetration  by  the  companies  that  adopted  them. 
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International  Findings  (5) 

The  Thales  Sea  Guardian  swimmer-detection  system  represents  an  example  of 
component  modularity.  An  integrated  port  security  system  with  extensible  geographic 
coverage,  a  forward  deployed  own-ship  protection  system,  or  a  mobile  search  system  can  be 
implemented  with  modular  mirror  sonar  elements.  Components  were  designed  with  the 
intent  of  becoming  elements  in  a  much  larger  adaptable,  modular  system. 
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Systems  Engineering  Findings 

Processes :  The  Panel  found  that  approaches  to  robust  systems  engineering  and  analysis  were 
incomplete,  due  to  poor  definition,  lack  of  understanding,  and  inconsistent  application  of  the 
elements  of  systems  engineering  and  systems  analysis. 

Systems  Engineers :  The  Panel  found  that  within  the  Navy  and  the  contractor  base,  clear 
evidence  of  an  erosion  in  the  number  of  the  systems  engineers  existed.  It  determined  that  the 
undergraduate  and  graduate-level  engineering  curricula  were  not  adequate  in  providing  the 
tools  needed  by  students  to  address  the  broad  horizontal  problems  of  net-centric  horizontal 
system-of-system  architectures. 

No  horizontal  integration'.  The  study  team  concluded  that  systems  engineering  and  systems 
analysis,  when  performed,  was  carried  out  at  a  platfonn  level  only;  thereby  perpetuating  the 
business-as-usual  “stovepiped”  results  that  do  not  cut  across  programs  in  a  horizontal 
manner. 


Systems-Engineering  Tools :  The  Panel  believes  that  robust  system-of-systems  tools  are 
required  to  perfonn  comprehensive  systems  engineering  and  systems  analysis.  That  process 
must  address  the  following  priorities:  (a)  complexity  of  systems;  (b)  CONOPS;  (c)  joint 
forces  integration  and  operations;  (d)  spiral  technology  development  and  insertion  options; 
and,  (e)  autonomous  and  semi-autonomous  systems. 

A  system-of-systems  process  also  must  consider  a  number  of  other  factors,  including 
interdependencies;  interface  requirements;  trade-space  explosion;  MOEs,  MOPs  and  trades; 
as  well  as  uncertainty  characterization  and  propagation.  Other  issues  to  be  explored  are  the 
ability  to  respond  to  changing  threats,  effective  developmental  T&E  planning,  total  cost  of 
ownership,  and  human  behavior  in  system  performance. 
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S&T:  The  Panel  found  no  evidence  that  the  S&T  community  is  integrated  into  the  systems 
engineering  enterprise  at  any  level.  The  separation  or  decoupling  occurred  at  the  system  and 
program  level.  The  study  found  no  interaction  activities  beyond  the  baseline  of  record,  such 
as;  planned  spirals  or  other  evolutionary  activities  of  the  future.  There  are  also  no  coherent 
S&T  activities  planned  or  implemented  to  cut  laterally  across  programs  of  record  in  any 
operational  domain  or  individual  Future  Naval  Capability  (FNC). 

NPS:  While  the  Navy  has  begun  to  develop  a  Systems  Engineering  Curriculum  at  the  NPS, 
it  has  not  implemented  a  post  graduation  assignment  policy  or  process  to  effectively 
capitalize  on  this  resource.  The  Panel  believes  that  the  NPS  curriculum  is  very  much  suited 
to  helping  solve  the  challenges  identified  by  this  study.  Its  graduates  are  ideally  suited  for 
assignment  to  the  Navy  organizations  that  could  best  employ  their  systems  engineering 
education  and  experience. 
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Literature  Survey  Findings 


•  Limited  information  on  DoD  implementations  of  modularity 

-  Critical  military  factors  (e.g.  mission  flexibility,  acquisition  tradeoffs) 
not  considered  in  modularity  optimization 

-  Some  studies  related  to  systems  engineering  and  modularity  to  Navy 
ships 

-  No  formal  DoD  analysis  with  explicit  focus  on  S&T  for  modularity 
and  systems  engineering 


•  Several  recent  articles  and  reports  have  explored  methodologies  for  design 
and  evaluation  of  modular  systems 

-  Some  preliminary  work  defining  degrees  and  types  of  modularity 

-  Focus  on  commercial  applications 

-  More  mature  for  software  than  hardware  -  but  still  largely  heuristic 


Literature  Survey  Findings 

The  Panel  carried  out  a  search  of  professional  literature  accessible  through  the 
Defense  Technical  Information  Center  (DTIC)  database  and  the  Georgia  Tech  library 
databases  in  the  areas  of  systems  engineering,  open  systems  architectures,  and  modularity. 
The  study  team  paid  special  attention  to  the  subject  of  modularity  with  respect  to  military 
systems. 

The  search  revealed  that  software  modularity  is  considered  a  more  mature  process 
than  hardware  modularity,  with  numerous  opinions  available  on  how  to  achieve  it.  The 
Software  Engineering  Institute  (SEI)  addresses  configuration  management,  training,  and 
certain  format  issues.  Educational  institutions  also  address  different  schemes  for  software 
modularity  in  their  computer  science  curricula.  Due  to  the  time  limitations,  the  search  did 
not  address  software  modularity  specifically. 

Extensive  literature  and  textbooks  are  available  on  systems  engineering,  open  systems 
architectures,  and  operational  analysis.  These  topics  have  been  combined  with  industrial 
systems  engineering  and  logistics  literature  and  are  focused  mainly  on  the  commercial 
market  and  manufacturing.  Significant  data  exists  on  the  need  for  and  setting  of  standards 
and  agreement  on  interfaces. 

The  modularity  of  military  systems,  particularly  ship  capability-swapping,  has  been 
addressed  in  summary  articles.  The  modularity  of  avionics  systems  for  mission  flexibility 
also  has  been  addressed,  but  only  at  a  high  level.  No  formal  DoD  analysis  was  obtained  that 
dealt  with  the  S&T  of  modular  systems. 

The  search  findings  indicated  that  the  use  of  modular  system  design  is  increasing  in 
commercial  manufacturing,  but  provide  no  general  agreement  as  to  the  proper  methodology 
for  implementation.  The  commercial  driving  functions  are  business  based  and  generally 
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result  from  reuse  of  parts,  logistics,  and  the  selection  of  parts  that  require  no  corporate 
development.  The  Panel  found  that  optimization  models  and  methodologies  are  being 
developed  that  attempt  to  quantify  the  degree  of  system  modularity.  These  efforts  tend  to  be 
focused  on  manufacturability,  connections,  and  component  reuse  of  the  product  and  are  still 
preliminary. 

A  discussion  of  the  driving  functions  or  optimization  criteria  and  methodologies 
necessary  for  developing  modular  military  systems  appear  to  be  missing.  Most  commercial 
systems  have  short  development  and  life  cycles,  relative  to  military  systems.  Consequently, 
commercial  systems  do  not  consider  technology  insertion,  technology  refresh,  maintenance, 
and  technology  obsolescence  in  the  optimization  or  quantification  process  to  the  extent 
needed  in  military  systems. 
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Needed:  Tools  and  Methodologies  for 
Evaluating  System  Decompositions 
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Tools  and  Methodologies 

From  the  literature  survey,  the  Panel  concluded  that  more  study  and  work  needs  to  be 
done  in  developing  the  tools  and  methodology  for  evaluating  system  decompositions. 

Alternate  decompositions  of  a  system  are  often  feasible,  and  can  be  valuable  in 
considering  the  costs,  benefits,  and  tradeoffs  associated  with  different  partitions  of  a  system 
into  modules  and  interfaces  among  modules.  Decomposition  of  systems  into  sets  of 
components  and  interfaces,  in  order  to  capture  dependencies  among  components  is  still  an  art 
and  may  remain  an  art  for  the  long  term.  However,  the  art  of  system  decomposition  can  be 
supported  and  extended  via  insights  derived  from  formal  and/or  informal  optimizations  of 
modularity,  based  on  elucidating  objectives  and  considering  more  global  cost  functions. 

There  has  been  preliminary  work  on  reasoning  about  the  goodness  of  alternate 
partitions  of  a  system  into  a  set  of  modules.  Such  work  promises  the  development  of  tools 
and  methodologies,  including  both  qualitative  approaches — aimed  at  assisting  designers  as 
they  probe  alternate  decompositions  so  as  to  build  insights — and  more  formal  quantitative 
optimization  methods.  These  tools  and  methodologies  can  be  used  to  build  insights  about  the 
value  of  alternative  partitions. 

Key  functions  of  tools  and  methodologies  supporting  analysis  of  alternate  partitions 
include:  (1)  the  capture,  in  an  explicit  manner,  of  multiple  objectives;  (2)  the  construction  of 
formal  utility  functions  that  identify  the  contributions  to  costs  and  benefits  of  different 
partitions,  based  on  attribute  configurations  associated  with  the  partitions;  and  (3)  a  method 
of  representing  and  searching  among  different  partitions,  on  whether  the  partitions  are 
constructed  manually,  automatically,  or  through  a  process  of  mixed-initiative  interaction, 
with  input  coming  from  both  engineers  and  automated  processes. 
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The  slide  on  the  previous  page  shows  that  the  utility  of  the  modularity  yielded  by  a 
specific  decomposition  may  depend  on  multiple  factors.  As  shown,  good  modular  designs 
must  consider  the  overall  utility  associated  with  balancing  the  costs  and  benefits  of  various 
factors.  Formal  objective  functions  may  be  constructed  that  express  the  overall  value  or 
utility  of  a  decomposition  as  a  utility  function,  that  takes  as  arguments  the  monetary  and 
mission-centric  costs  of  building,  maintaining,  and  deploying  a  system. 

With  the  use  of  a  formal  utility  function,  the  contributions  of  multiple  factors  can  be 
scaled  to  a  uniform  measure  of  value,  such  as  dollars.  Such  an  approach  permits  even  non¬ 
monetary  factors  such  as  the  unavailability  of  a  component  or  system  during  a  critical 
mission  to  be  mapped  to  a  dollar  value.  For  example,  in  order  to  consider  the  merit  of 
different  partitions.  Also,  uncertainty  in  attributes  or  in  cost  can  be  considered  explicitly 
with  the  assessment  from  data  or  from  experts  of  probability  distributions  over  these 
outcomes,  and  such  probability  distributions  can  be  employed  to  generate  expected  values  of 
alternate  designs. 
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Summary  Findings 


Navy  Programs  -  implementation  of  modularity  delegated 
to  primes;  no  horizontal  systems  engineering 

U.S.  Defense  Industry  -  systems  engineering  and 
modularity  not  uniformly  applied  within  programs 

International  industry  -  ahead  of  the  U.S.  defense  industry 
injudicious  use  of  modularity 

Systems  Engineering  -  systems  engineering  fundamental  to 
implementing  modularity  but  current  practice  inadequate 

Literature  Survey  -  early  work  on  methodologies  for 
decomposition  of  systems 


Summary  Findings 

The  Panel  summarized  the  study  findings  in  five  areas:  Navy  programs,  U.S.  defense 
industry,  international  industry,  systems  engineering,  and  literature  survey.  It  concluded  that 
for  Navy  programs,  implementation  of  modularity  is  delegated  usually  to  prime  contractors 
without  adequate  horizontal  systems  engineering  analysis.  This  shortcoming  highlights  a 
structural  issue  with  the  current  program-centric,  or  stove-piped  systems  acquisition  process. 
Currently,  modularity  is  being  pursued  only  on  a  program-by-program  basis,  with  little 
specific  guidance  on  what  modularity  is,  and  how  or  why  it  is  to  be  used. 

No  mechanism  in  the  Navy  ensures  that  modularity  is  focused  across  programs  to  the 
overall  benefit  of  the  Navy.  Individual  programs  do  not  have  the  charter  or  ability  to  do  so, 
and  prime  contractors  are  only  able  to  work  across  programs  within  “their  own  house.” 
System-of-systems  concepts  will  continue  to  suffer  unless  this  issue  is  addressed. 

The  Panel  concluded,  that  within  the  U.S.  defense  industry,  systems  engineering  and 
modularity  are  not  uniformly  applied  within  programs.  Panel  members  observed  that 
virtually  all  companies  embraced  the  concepts  of  modularity  and  systems  engineering,  but 
understanding  and  implementations  of  these  concepts  varied  widely.  Because  of  the  absence 
of  uniform  Navy  guidance  and  definitions,  each  program  had  established  de  facto  operating 
definitions  and  guidance. 

Systems  developed  using  the  four  categories  of  modularity  (defined  by  the  Panel)  will 
not  necessarily  be  interoperable  or  mutually  compatible.  The  missing  ingredient  is  systems 
engineering  at  the  system-of-systems  level,  to  ensure  requirements  have  been  traded  and 
coordinated  horizontally  across  programs  to  achieve  interoperability. 

In  the  international  area,  European  companies  examined  were  ahead  of  the  U.S. 
defense  industry  injudicious  use  of  modularity.  This  advantage  appears  to  have  been  driven 
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by  economics.  The  European  programs  have  been  forced  by  budgetary  constraints  into 
forming  joint  customer/contractor  teaming  and  adopting  specifically  defined  modularity 
concepts  for  cost  avoidance  or  have  done  so  in  order  to  tailor  products  to  a  diversity  of 
customers  and  missions.  The  Panel’s  observations  did  not  extend  to  an  assessment  of 
operating  effectiveness  or  functional  suitability. 

A  key  finding  was  that  systems  engineering  is  fundamental  to  implementing 
modularity.  The  Panel  recommended  that  the  Navy  perform  up  front  system-of-systems 
analysis  and  synthesis,  which  is  currently  either  not  done,  or  inadequately  done. 

Prime  contractors  typically  have  “in  house”  rules  and  definitions  for  systems 
engineering,  but  they  typically  do  not  consider  cross-platform  operations,  unless  specifically 
directed  to  do  so.  Furthermore,  there  appeared  to  be  a  shortage  of  appropriately  qualified, 
experienced  systems  engineering  staff  within  both  DOD  and  the  U.S.  defense  industry. 

The  Panel  devoted  considerable  effort  to  a  search  of  literature  on  modularity.  The 
single  most  important  finding  of  the  literature  search  is  that  significant  efforts  currently  are 
being  initiated  to  address  the  issues  of  decomposition  strategies/techniques  and  metrics  for 
measuring  the  merits  of  various  competing  strategies.  These  efforts  have  a  high  potential 
payoff  and  would  be  an  excellent  area  of  focus  and  research  for  the  Navy. 
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The  Panel  found  that  effective  modularity  in  naval  systems  must  be  derived  from  a 
system-of-systems  level  analysis  cognizant  of  operational  and  business  drivers,  technology, 
deployment,  and  life-cycle  issues.  The  Panel  concluded  that  many  Navy  and  DoD  programs 
are  at  an  early  enough  stage  to  benefit  from  this  type  of  cross-cutting  analysis  and 
engineering.  The  study  members  found  early  stage  research  suggesting  that  modularity  can 
be  derived  from  a  rigorous  analysis  methods  and  explicit  optimization.  Accordingly,  the 
study  recommendations  address  the  Navy  leadership  at  several  levels. 

First,  the  current  acquisition  structure  makes  it  difficult  to  implement  cross-cutting, 
horizontal  systems  engineering  and  analysis  across  program  lines.  The  Panel  urged  the  Vice 
CNO,  the  Assistant  Commandant  of  the  Marine  Corps  (CMC),  and  the  ASN  (RD&A)  to 
direct  the  development  of  a  naval-wide,  system-of-systems  engineering  function  to  enable  a 
broader  perspective  than  that  acceptable  for  a  single  acquisition  program.  This  approach  also 
could  empower  a  capabilities  based  perspective  rather  than  platform-based  view  in  the 
development  of  future  warfighting  requirements  and  systems. 

The  Panel  discussed  several  possible  organizational  alignments  of  such  a  function, 
but  did  not  reach  a  consensus.  Support  from  the  senior  naval  leadership  is  essential  for  such 
a  systems  engineering  function  to  gain  traction  and  enable  truly  transfonnational  warfighting 
capability.  It  is  therefore  most  appropriately  placed  where  the  naval  leadership  can  ensure 
empowerment. 

Secondly,  the  Panel  concluded  that  effective  modularity  only  results  from  a  clear 
understanding  of  motivating  factors.  Different  types  and  degrees  of  modularity  result  from 
different  motivations.  For  example,  if  the  primary  driver  of  the  Navy’s  future  warfighting 
capability  is  total-cost  of  ownership  in  a  highly  uncertain  threat  environment,  the  resulting 
modular  systems  likely  will  be  somewhat  different  than  if  the  primary  driver  was  the  ability 
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to  leverage  commercial  technology  development.  It  is  critical  that  the  driving  factors  for 
systems  engineering  that  support  modular  decomposition  of  acquisition  programs  are  clearly 
articulated,  universally  understood,  and  accurately  specified.  The  Panel  felt  that  this  policy 
guidance  should  come  from  the  CNO/CMC  level. 

Lastly,  the  technology  for  optimizing  module  selection  is  potentially  rich,  but  still 
immature.  The  Panel  recommended  that  the  CNR  serve  as  a  change  agent  and  focus  on  the 
tools  that  would  enable  optimal  decomposition  of  systems  and  selection  of  modules. 
Additional  technology  is  required  to  support  cross-cutting  systems  engineering  analysis, 
specifically  top-level  modeling  and  simulation  tools.  There  is  also  a  need  for  development  of 
advanced  concepts  and  tools  that  enable  software  reuse.  Finally,  the  Panel  endorsed  the  use 
of  experimentation  and  innovative  prototypes  to  develop  and  test  modularity  concepts  and  to 
support  spiral  development. 
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Requirements  Community  Needs  to  Drive 
Modularity  Guidelines  Horizontally 


Establish  Navy  Systems  Engineering  &  Analysis  Function 


Modularity  Guidelines 

The  slide  above  defines  the  Panel’s  version  of  a  naval- wide  systems-of-systems 
engineering  and  analysis  function.  Such  a  function  would  receive  input  from  ah  of  the 
leadership  and  acquisition  entities  (OSD,  Navy  Secretariat,  fleet,  OPNAV,  and  the 
acquisition  community),  analyze  these  inputs,  carry  out  tradeoff  studies,  develop  a  gap 
analysis  of  current  programs  of  record,  and  give  direction  that  could  shape  FNCs  and 
influence  naval  R&D  investment.  This  function  should  rely  on  systems  engineering  and 
analysis,  using  structured  methods  and  tools,  across  the  entire  spectrum  of  naval  programs  to 
ensure  that  future  guidance  is  compatible  with  naval  mission  needs  and  modularity  drivers. 
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Conclusions 


The  time  is  right  to  harvest  value  from  modularity 
through  disciplined  Systems  Engineering 

Implementing  System  of  Systems  Engineering  and 
adopting  modularity  effectively  can  result  in: 

•  Flexible  and  interoperable  warfighting  systems  that 
can  better  address  an  uncertain  future 

•  Ability  to  cope  with  limited  resources 


Conclusions 

The  study  looked  at  a  comprehensive  range  of  data  and  perspectives  on  the  value  of 
modular  designs  for  Navy  acquisition  programs.  The  Panel  concluded  an  undeniable  value  in 
modular  approaches,  as  demonstrated  in  the  international  arena,  and  for  several  major  Navy 
programs.  However,  the  Panel  emphasizes  that,  depending  on  the  findings  of  a  meticulous 
systems  engineering  assessment  of  drivers  and  tradeoffs,  modular  design  may  not  be 
necessary  or  appropriate  for  some  types  of  systems. 

The  value  of  modular  design  is  shown  to  pay  clear  dividends  for  advanced  systems 
that  incorporate  commercial  components  and  subsystems,  as  commercial  vendors  move 
decisively  towards  modularity.  The  value  of  a  modular  approach  for  the  LCS,  SSGN,  and 
ARCI  programs  is  indisputable,  in  terms  of  enhancing  interoperability  and  supportability, 
while  cutting  costs — all  critical  priorities  for  today’s  Navy.  The  benefits  of  construction 
modularity  have  been  validated  extensively  in  ship  and  aircraft  construction. 

The  in-depth  explorations  that  support  the  Panel’s  findings  showed  the  clear  impact 
of  modular  design  for  platforms,  weapon  systems,  and  subsystems.  Nevertheless,  the  study 
also  revealed  that  the  Navy  has  not  established  the  policy  and  direction  that  are  essential  to 
guide  acquisition  managers  to  consider  the  value  of  modular  design  for  their  programs  and 
implement  consistent  modularity  principles.  For  that  reason,  the  Panel  urges  naval  leadership 
at  the  highest  levels,  within  the  Secretariat  and  the  operational,  acquisition,  and  the  S&T 
communities,  to  adopt  the  study’s  recommendations  and  establish  that  policy  and  that 
direction,  as  they  seek  to  preserve  and  extend  the  capabilities  of  the  fleet  for  a  new  century  in 
the  midst  of  increased  resource  pressures. 
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Appendix  A 


Terms  of  Reference 
S&T  for  Modular  Systems 


Objective 

To  review  and  assess  the  relationship  of  Science  &  Technology  (S&T)  to  modular  systems 
acquisitions,  systems  engineering,  open  architectures  and  spiral  development  and  make 
recommendations  for  improving  these  relationships  where  appropriate. 

Background 

New  systems  are  being  developed  using  open  system  architectures  and  modular  constructs 
that  allow  for  "flexible  mission  modules",  spiral  development  enhancements  as  technologies 
mature,  and  interoperability  in  net-centric  systems  of  systems.  Examples  include  LCS, 
MMA,  BAMS,  SSGN,  DD(X),  F-35,  JTRS  and  X-Craft.  Robust  systems  engineering 
practices  will  be  key  to  the  success  of  these  efforts. 

Minimal  work  has  been  done  to  investigate  whether  S&T  programs,  with  potential 
application  to  multiple  types  of  systems  and  mission  packages,  can  or  should  be  planned  in 
conjunction  with  acquisition  systems  engineering.  There  could  be  high  payoffs  if  advanced 
capabilities  could  be  developed  in  S&T  with  a  "modular"  vision.  Payoffs  could  be  realized 
in  terms  of  faster  transition,  lower  development  costs,  economies  of  scale  for  production, 
reduced  logistic  support  costs,  and  decreased  training  requirements. 

If  systems  engineering  analysis  is  done  at  the  early  stages  of  concept  development  with  the 
involvement  of  the  S&T  community,  the  needs  of  future  mission  modules  and  spiral 
upgrades  can  be  used  to  guide  S&T  investments.  This  may  require  a  more  structured  type  of 
interaction  between  the  S&T  and  acquisition  communities  than  currently  exists. 

Specific  Taskings 

This  study  will  specifically  address  the  linkage  between  the  S&T  community  and  modular 
system  developments. 

•  Review  and  assess  Navy  systems  engineering  efforts  on  programs  of  record  and  the 
extent  to  which  modular  open  systems  and  provisions  for  spiral  upgrades  and  S&T 
are  factors  in  the  requirements  definition  and  acquisition  processes. 

•  Identify  candidate  high-payoff  S&T  areas  for  modular  development  and  horizontal 
integration;  and  assess  the  opportunities  for  S&T  engagement  with  systems 
engineering  efforts. 
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•  Where  appropriate,  recommend  guidelines  for  structuring  modular  S&T  initiatives 
that  would  enable  utilization  of  results  in  multiple  platforms/missions  packages. 

•  Recommend  changes  required  to  improve  the  interface  between  Navy's  S&T  planning 
and  acquisition  processes. 
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Appendix  B 

Acronyms 


ACAT  Acquisition  Category 

ACS  Aerial  Common  Sensor 

ARCI  Acoustic  Rapid  (COTS)  Insertion 

ASN  (RD&A)  Assistant  Secretary  of  the  Navy  (Research,  Development  and  Acquisition 


BAMS 

Broad  Area  Maritime  Surveillance 

CMC 

Commandant  of  the  Marine  Corps 

CNO 

Chief  of  Naval  Operations 

CONOPS 

Concepts  of  Operation 

COTS 

Commercial  of-the-Shelf 

CPU 

Central  Processing  Unit 

CRD 

Concept  Requirements  Document 

DASN 

Deputy  Assistant  Secretary  of  the  Navy 

DOD 

Department  of  Defense 

DoN 

Department  of  the  Navy 

DT 

Development  Testing 

DTIC 

Defence  Technical  Information  Center 

FNC 

Future  Naval  Capability 

HDW 

Howaldtserke-Deutsche  Werft 

HSV 

High  Speed  Vessel 

IDS 

Integrated  Deepwater  Systems 

JTRS 

Joint  Tactical  Radio  System 

J-UCAS 

Joint  Unmanned  Combat  Air  System 

LCS 

Littoral  Combat  Ship 

LMW 

Littoral  Mine  Warfare 

MIT 

Massachusetts  Institute  of  Technology 

MMA 

Multi-Mission  Aircraft 

MOE 

Measure  of  Effectiveness 

MOP 

Measure  of  Performance 

MOSA 

Modular  Open  Systems  Architectures 

MOU 

Memorandum  of  Understanding 

NAVSEA 

Naval  Sea  Systems  Command 

NMT 

Navy  Multi-Band  Tenninal 

NPS 

Naval  Post  Graduate  School 

NRAC 

Naval  Research  Advisory  Committee 

ONR 

Office  of  Naval  Research 

OSD 

Office  of  the  Secretary  of  Defense 

OSJTF 

Open  Systems  Joint  Task  Force 

OT 

Operational  Testing 

PEO 

Program  Executive  Officer 

PM 

Program  Manager 

POM 

Program  Objective  Memorandum 

RDT&E 

Research,  Development,  Test  &  Evaluation 

B-l 

RF 

Radio  Frequency 

S&T 

Science  &  Technology 

SEI 

Software  Engineering  Institute 

T&E 

Test  and  Evaluation 

TOR 

Terms  of  Reference 

UUV 

Unmanned  Underwater  Vehicle 
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